View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000533 | T99X171.00 SKB Eagle | SW Issue | public | 2019-03-04 17:08 | 2019-08-30 16:43 |
| Reporter | Assigned To | Due Date | |||
| Priority | immediate | Severity | s1-catastrophic | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000533: RCU BT Pairing_Connection Failure | ||||
| Description | It has been encountered that RCU BT connection is failed at all times when trying to connect again after releasing BT pairing. [Test Procedure] 1. Make sure that RCU BT Pairing works well 2. Rebooting 3. Verify if RCU BT is connected well by BT auto connection 4. Release BT pairing if RCU BT connection is done well 5. Trying to connect RCU BT again 6. Verify if there is no issue on connecting RCU BT [Actual Result] BT connection is always failed when trying to connect it again after releasing BT pairing. The following error toast popup is displayed; [Device Search Fail, code 33] In addition, we cannot collect the bugreport log by the logging is stopped at 60 ~ 70% or by STB rebooting due to any crash. | ||||
| Steps To Reproduce | Please refer to above description. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| User List |
|
|---|
|
|
Hi Eric, We will try to duplicate this issue at our side. However, could you provide which FW version your are testing? |
|
|
We received and tested this issue with SW V 15.502.3. |
|
|
I checked with SW v 15.502.3. 1. STB - no paired, RCU - no paired - Start Pairing - OK We can see BMM_BA01_xxx and BMM_Audio_BA01 in RCU & Acc. list in Home - TVApp - Google setting menu. - Start Unpairing We can see BMM_BA01_xxx and BMM_Audio_BA01 in RCU & Acc. list. I think this situation is RCU - Unpaired / STB - paired In this case we cannot repair again. It displayed error message of RCU Pairing Fail. But we unpair BMM_BA01_xxx and BMM_Audio_BA01 in RCU & Acc. list first. And check that there is no device in RCU & Acc. list. In this situation, we can repair again without issue. 2. STB - paired, RCU - paired - Start unpairing We start unpair with menu in RCU & Acc. list in Home - TVApp - Google setting menu. And we check that there is no device in RCU & Acc. list. - Start pairing again In this situation, we can pair again without issue. I hope it is helpful to your investigation. In case of Kaon STB, there is no issue on case 1. |
|
|
We tried to duplicate your Case 1, We use Google settings Menu to unpair. After Unparing, we see empty list in Google settings Menu (Remotes & Accessories) We think RCU is still in paired mode after we press unpair in settings menu. |
|
|
|
|
|
We can check the action of RCU when it unpaired as follow: Bluetooth pairing Reset (Unpairing) Scinario 1. Push the button [*] +[홈home] key for 3 seconds 2. LED blink (ON: 100ms, OFF: 100ms) 5 times quickly if BT Unpair is finished normally > Power Off Audio BT, BT Unpair is finished normally > If connected, do unconnect and go Unpair process Please refer "Operationg scenario tab" of SKB_RCU_BA01_Protocol_Rev0.2_Eng.xlsx. It already provided to Foxconn but I attached it again. |
|
|
I've heard from SKB on other STB on BT. Other STB has BT issue on reconnection and stability. SKB engineer said that other STB got some other firmware from BT vendor on PLE. They fixed the issue after disabled Data Packet Length Extension was disabled. I'm not sure it is the solution or not on our issue. Please check it Data Packet Length Extension. |
|
|
Do you know which BT device have reconnection and stability issue on other STB? However, we will try your unpairing method to duplicate repairing issue again and get back to you our result. |
|
|
We have 2 kinds RCU. We tested with Movon RCU. It works at first pairing without issue. But RemoteSolution RCU cannot pair with current SW. I never paired with RemoteSolution RCU. Did you check it with RemoteSolution RCU. |
|
|
SKB asked us to release the plan to fix this issue. Please update your schedule. |
|
|
We could duplicate this issue (Case 1) on our office. The due date to fix this issue is 3/11. |
|
|
The root cause of this issue is that BMM_BA01_xxx still exists in RCU & Acc. list. In such situation, BT stack will not report boned devices to application. Therefore, RCU pairing will fail at discovering devices. To solve this issue, we remove bonded device once RCU starts to pair. |
|
|
I upload a test image for RCU repair issue. Please get file from URL below: https://drive.google.com/file/d/1jw-uOSniFQVveJNLXhzgmGGjCI2sbG1p/view?usp=sharing Note: This image is ONLY for RCU repair issue verification. |
|
|
Hi Eric, Please help to confirm RCU repair failed issue on test image. After we get your confirmation, we will close this issue and commit source to git server. For RemoteSolution RCU pairing issue, I suggest to create another issue for tracking. Thank you ! |
|
|
Dear SY Yoon, Please update the test result based on your reproducible case (1) |
|
|
In case of Case 1, I think that it works fine. I didn't test enough, because there are some BT devices that always try pairing in danam building I will test it with official SW release. And I found another issue. I call it Case 2. Case 2. Multi RCU pairing issue Test Sequence : There are 2 RCU, RCU A and RCU B. 1. Pair with RCU A. Check the result 2. Unpair with RCU A and Pair with RCU B. Check the result. Test Result : STB disconnect RCU A, but RCU B didn't pair. Comment : If I unpair RCU A and delete Device ID in BT device list in Google menu before start RCU B pair, I can pair RCU B. Please you check and fix it. |
|
|
Hi SY Yoon, For Case2, We add a program to remove RCU A while user starts to pair RCU B in the test image. Please check again, thank you ! |
|
|
I tested it 6th times. 1 ~ 5 th trial was success. 6th trial was fail. After that I cannot pair any more. I rebooted STB, and tested again. Sometimes it successed and sometimes failed. Mr. Jin Chen said to me that it will be better if I use changed HW. So I didn't test any more. I will check it again with changed HW later. |
|
|
Hi Kerwin, Just flashed to v15.502.6, but BT connection is failed when trying it for the first time after flashing(upgrading F/W version). The strange thing is that IR also is not operated after the pop-up on BT connection failure is displayed Please check the attached log, adb_log_1.7z. as soon as you can. |
|
|
Hi all Sean recommended that BT Pairing will be improved for changing load capacitor of BT xtal. I changed load cap 8.2nF and test BT pairing. but the BT pairing is not still work well. |
|
|
Hi Mr. Yoon, Eric and SB, We did many tests on different commit on git server and get a clue of this issue. After we have a solution, we will let you know. Thanks for your help ! |
|
|
If you have any test version, then please provide it. We will test it. |
|
|
We will release a new FW with fixes of BT RCU pairing. However, we notice that sometimes error code 11 also happens on Kaon box even RCU SW is upgraded to 1.30. Please help to check and report this issue to UEI. Thanks ! |
|
|
Is there no issue with RCU SW v 1.20(it can be upgrade with previous SW V 15.502.8) or 1.10(It was RCU SW version without OTA) ? I've heard that new SW changed only for power consumption. If you don't have any issue on SW V1.10 or 1.20, please let us know. |
|
|
Hi Mr. Yoon, The error code 11 also happens on previous RCU SW. Let us back to STB SW V15.502.9, we remove our unpair software to avoid thread timing issue in BT stack. How is the test result ? |
|
|
Hi Kerwin, Just verified BT behavior with v15.502.9. The behavior on BT pairing and connection got better over all, and also BT behavior both for retrying BT connection with the same RCU and for trying BT connection with another RCU got better than previous one. Both the behavior after BT connection is failed and the failure frequency are similar with the reference STB. However, there is one critical issue, which is that the error code 33 keeps being encountered from some moment all of a sudden, and this issue has been encountered even rebooting STB. For your reference, this issue has been disappeared when retying BT pairing again after the error code 11 is suddenly encountered Please check the following issue and inquiries and get back to us. 1) Why the error code 33 keeps being encountered? 2) Please explain what is the meaning of each error code(11, 33, 14) 3) Now BT connection is available for RemoteSolution RCU(STB done HW ECO when looked with the naked eye). Please let us know what are the change description and the root cause on RemoteSolution RCU issue if you have integrated any solution in SW side. |
|
|
Hi Eric, The error code 33 means "Scanning fail", STB can't find any RCU to connect. Since STB is able to receive advertising packets from other devices, I think RCU is not in connectable state or it is already paired with other STB. You can use another device (such as mobile phone) to check if RCU keeps sending advertising packets while pairing with STB. For your inquiries, please check replies as below: 1) As I explain above, RCU needs to send advertising packet. Otherwise, error code 33 will happen. 2) Those error codes is defined by TVS' pairing program, not from BT stack. 3) From SW side, there is no difference for these 2 RCUs. |
|
|
included in v15.502.9 |
|
|
Hi Kerwin, To exclude the environmental factor that you mentioned, conducted these kinds of test under the environment that STB 1 + RCU 2(SW version for both RemoteSolution and Mobon is the latest one, v1.30) are just present. However, the following issue have still occurred, so we need to know exactly what is the root cause so that we can let SKBB managers explain whether there would be no issue from STB own or not since these kinds of issues could be encountered in the process of the official QA and BMT test. Those issues are as follows. Issue 1) Error code 14 is occurred when trying doing BT pairing between A(Mobon) RCU and B(RemoteSolution) RCU -. In other words, trying doing BT connection with B RCU under A RCU is paired with STB, and continue to do BT connection alternately . -. Please check Issue_1.7z log Issue 2) In the process of trying doing BT pairing between A(Mobon) RCU and B(RemoteSolution) RCU, the error code 11 is encountered when trying to pair BT with B RCU, then retrying to pair BT with the same RCU(B RCU) and the error code 33 is occurred. -. Please check why the error code 11 and 33 are occurred. -. You can refer to Issue_2.7z.log Issue 3) In the process of trying doing BT pairing between A(Mobon) RCU and B(RemoteSolution) RCU, Both A RCU and B RCU are in BT mode and STB indicated as BT connection is established with A RCU. At this time, trying to pair BT with B RCU but the error code 11 is occurred. -. Please check Issue_3.7z.log I'd like to highlight again that we have to know why the error codes(11, 33, 14) are encountered under the environment which cannot be affected by other STBs and RCUs. |
|
|
Hi Eric, Per talk this morning, please set trace level of BT to '5' in config file ( /etc/bluetooth/bt_stack.conf ). We notice that sometimes STB can't get 'RemName' from RCU and results in error code 11. This issue also happens on Kaon's box. We will continue to check other issues during RCU pairing. |
|
|
Hi Kerwin, Collected logs by BT trace level 5 under RCU v1.3 + the correct BT MAC + BT improvement version(v15.502.10 = r9). Please check log_error 11.zip for error code 11 and log_error 14.zip for error code 14. For your refernce, you can ignore the log related to error code 33 from each log since the error code 33 has been caused by RCU's battery removal. |
|
|
Hi Kerwin, Thanks for your active support. Please also check the log on the error code 33. The reproduciable path is as follows. 1) Booting STB 2) STB and RCU are in BT connection state, but no key is operated 3) After unpairing via [*]+[Home], trying to pair BT via [NUGU] key 4) But there is no response after the popup, "trying to connect BT", is displayed 5) Trying [NUGU] key again, but error code 33 is encountered 6) Trying [NUGU] key again and BT connection is OK |
|
2019-04-11 09:43 developer |
|
|
|
Hi Kerwin, As we reviewed the relevant logs, you've suspected that the error code 33 could be caused by RCU's defect that RCU doesn't send "Remote Name"(is empty) or RCU send " the cause of Remote User Disconnect". So we would be grateful if you could update any evidence on RCU's defect and explain the cause for other errro codes(11 and 14). |
|
|
Hi Mr. Yoon and Eric, I create another issue to track error code 11. (https://172.18.223.170/vaas/view.php?id=662) For error code 33, let's move to 'https://172.18.223.170/vaas/view.php?id=617' to discuss. We will include a fix for error code 14 on 4/25. Please close this issue after verifying the fix for error code 14. Thanks ! |
|
|
Hi Kerwin, It will try to verify the error code 14 with r15 version. In the meantime, please let us know what is the root cause for error code 14. Thanks for your cooperation. |
|
|
Hi Eric, The root cause of error code 14 is connection interval too long to get HID descriptor from RCU. We set the interval from 48.75ms to 11.25ms to solve it. |
|
|
Hi Kerwin, Thanks for your information. In fact, it's hard for me to understand your explanation. You said that it took too long to get HID descriptor from RCU and the solution was to shorten the interval to 11.25. But I cannot make sense why it should rather shorten the interval in spite of taking too long to get HID descriptor. Sorry, could you let me know in more detail? |
|
|
Hi Eric, The Connect interval is used to determines how often the STB will ask for data from the RCU. Shorten connect interval will improve data throughput, so STB can get all HID descriptors in time. |
|
|
Hi Kerwin, Thanks for your valuable information. Tried to reproduce the error code 14 issue but it has not been reproduced yet even if other error codes(11, 33) have still been observed. So the error code 14 issue seems to be fixed. Thanks for your efforts. |
|
|
included in v15.502.15 |
|
|
this ticket is too long so close it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-03-04 17:08 |
|
New Issue | |
| 2019-03-04 17:08 |
|
Status | new => assigned |
| 2019-03-04 17:08 |
|
Assigned To | => (SW) Jacky Chiang |
| 2019-03-04 17:09 |
|
Issue Monitored: (ALTech) Eric Kim | |
| 2019-03-04 17:10 |
|
Issue Monitored: (ALTech) Jewoo Lee | |
| 2019-03-04 17:11 |
|
Issue Monitored: (ALTech) SY Yoon | |
| 2019-03-04 17:12 |
|
Issue Monitored: (ALTech) SB Park | |
| 2019-03-04 17:21 |
|
Description Updated | |
| 2019-03-04 17:23 |
|
Summary | RCU BT Pairing Failure => RCU BT Pairing and connection Failure |
| 2019-03-04 17:24 |
|
Summary | RCU BT Pairing and connection Failure => RCU BT Pairing_Connection Failure |
| 2019-03-04 17:50 | (SW) Jacky Chiang | Assigned To | (SW) Jacky Chiang => (SW) Jim Chen |
| 2019-03-04 17:50 | (SW) Jacky Chiang | Issue Monitored: (SW) Jacky Chiang | |
| 2019-03-04 17:51 | (SW) Jacky Chiang | Issue Monitored: (SW) Kerwin Chen | |
| 2019-03-04 17:51 | (SW) Jacky Chiang | Note Added: 0001299 | |
| 2019-03-04 17:52 | (SW) Jacky Chiang | Note Edited: 0001299 | |
| 2019-03-04 19:58 | (ALTech) SY Yoon | Note Added: 0001303 | |
| 2019-03-04 20:09 | (SW) Jacky Chiang | Issue Monitored: (SW) Jason Ling | |
| 2019-03-05 15:18 | (ALTech) SY Yoon | Note Added: 0001316 | |
| 2019-03-05 16:30 | (ALTech) SY Yoon | Note Edited: 0001316 | |
| 2019-03-05 20:21 | (SW) Jacky Chiang | Assigned To | (SW) Jim Chen => (SW) Jason Ling |
| 2019-03-05 20:21 | (SW) Jacky Chiang | Issue Monitored: (SW) Jim Chen | |
| 2019-03-05 20:55 |
|
Note Added: 0001332 | |
| 2019-03-06 09:36 | (ALTech) SY Yoon | File Added: SKB_RCU_BA01_Protocol_Rev0.2_Eng.xlsx | |
| 2019-03-06 09:36 | (ALTech) SY Yoon | Note Added: 0001342 | |
| 2019-03-06 11:58 | (ALTech) SY Yoon | Note Added: 0001350 | |
| 2019-03-06 12:06 | (SW) Jacky Chiang | Note Added: 0001352 | |
| 2019-03-06 12:07 | (SW) Jacky Chiang | Note Edited: 0001352 | |
| 2019-03-06 16:49 | (SW) Jacky Chiang | Assigned To | (SW) Jason Ling => (SW) Kerwin Chen |
| 2019-03-06 18:15 | (ALTech) SY Yoon | Note Added: 0001363 | |
| 2019-03-06 19:13 | (ALTech) SY Yoon | Note Added: 0001369 | |
| 2019-03-06 21:15 | (SW) Kerwin Chen | Note Added: 0001377 | |
| 2019-03-08 18:07 | (SW) Kerwin Chen | Note Added: 0001420 | |
| 2019-03-11 17:54 | (SW) Kerwin Chen | Note Added: 0001441 | |
| 2019-03-12 12:10 | (SW) Kerwin Chen | Assigned To | (SW) Kerwin Chen => (ALTech) Eric Kim |
| 2019-03-12 12:13 | (SW) Kerwin Chen | Note Added: 0001456 | |
| 2019-03-13 11:04 |
|
Assigned To | (ALTech) Eric Kim => (ALTech) SY Yoon |
| 2019-03-13 11:06 |
|
Note Added: 0001488 | |
| 2019-03-13 22:59 | (ALTech) SY Yoon | Note Added: 0001513 | |
| 2019-03-15 18:41 | (SW) Kerwin Chen | Note Added: 0001560 | |
| 2019-03-15 21:18 | (ALTech) SY Yoon | Note Added: 0001563 | |
| 2019-03-19 09:51 |
|
File Added: adb_log_1.7z | |
| 2019-03-19 09:51 |
|
Note Added: 0001589 | |
| 2019-03-19 09:59 |
|
Assigned To | (ALTech) SY Yoon => (SW) Kerwin Chen |
| 2019-03-19 14:05 |
|
Category | SW => SW Issue |
| 2019-03-19 21:12 |
|
Note Added: 0001612 | |
| 2019-03-20 18:13 | (SW) Jacky Chiang | Issue Monitored: (SW) Gary Hsu | |
| 2019-03-27 09:14 | (SW) Kerwin Chen | Note Added: 0001719 | |
| 2019-03-27 15:04 | (ALTech) SY Yoon | Note Added: 0001742 | |
| 2019-04-01 10:32 | (SW) Kerwin Chen | Note Added: 0001785 | |
| 2019-04-01 11:56 | (ALTech) SY Yoon | Note Added: 0001792 | |
| 2019-04-02 13:38 | (SW) Kerwin Chen | Note Edited: 0001785 | |
| 2019-04-02 14:15 | (SW) Kerwin Chen | Note Added: 0001812 | |
| 2019-04-02 15:07 |
|
File Added: btsnoop_hci.log | |
| 2019-04-02 15:07 |
|
File Added: Keep failing_2_even rebooting_LogFilter_20190402_153651.txt | |
| 2019-04-02 15:07 |
|
Note Added: 0001819 | |
| 2019-04-02 15:11 |
|
Note Edited: 0001819 | |
| 2019-04-02 15:52 |
|
Note Edited: 0001819 | |
| 2019-04-02 15:53 |
|
Note Edited: 0001819 | |
| 2019-04-02 20:01 | (SW) Kerwin Chen | Note Added: 0001832 | |
| 2019-04-02 20:02 | (SW) Kerwin Chen | Assigned To | (SW) Kerwin Chen => (ALTech) Eric Kim |
| 2019-04-02 20:02 | (SW) Kerwin Chen | Status | assigned => resolved |
| 2019-04-02 20:02 | (SW) Kerwin Chen | Resolution | open => fixed |
| 2019-04-02 20:02 | (SW) Kerwin Chen | Note Added: 0001833 | |
| 2019-04-03 16:42 |
|
File Added: Issue_1.7z | |
| 2019-04-03 16:42 |
|
File Added: Issue_2.7z | |
| 2019-04-03 16:42 |
|
File Added: Issue_3.7z | |
| 2019-04-03 16:42 |
|
Note Added: 0001861 | |
| 2019-04-03 16:43 |
|
Assigned To | (ALTech) Eric Kim => (SW) Kerwin Chen |
| 2019-04-03 16:43 |
|
Status | resolved => assigned |
| 2019-04-10 11:56 |
|
Resolution | fixed => open |
| 2019-04-10 13:49 | (SW) Kerwin Chen | Note Added: 0001958 | |
| 2019-04-10 18:23 |
|
File Added: log_error 14.zip | |
| 2019-04-10 18:23 |
|
File Added: log_error 11.zip | |
| 2019-04-10 18:23 |
|
Note Added: 0001974 | |
| 2019-04-11 09:43 |
|
Note Added: 0001981 | |
| 2019-04-11 09:43 |
|
File Added: log_error_33.zip | |
| 2019-04-15 09:07 |
|
Note Added: 0001998 | |
| 2019-04-24 20:31 | (SW) Kerwin Chen | Note Added: 0002183 | |
| 2019-04-24 20:34 | (SW) Kerwin Chen | Assigned To | (SW) Kerwin Chen => (ALTech) Eric Kim |
| 2019-04-29 12:53 |
|
Note Added: 0002245 | |
| 2019-04-29 13:25 | (SW) Jacky Chiang | Assigned To | (ALTech) Eric Kim => (SW) Kerwin Chen |
| 2019-04-29 13:36 | (SW) Kerwin Chen | Note Added: 0002250 | |
| 2019-04-29 14:12 |
|
Note Added: 0002253 | |
| 2019-04-29 17:38 | (SW) Kerwin Chen | Note Added: 0002288 | |
| 2019-04-29 17:46 |
|
Note Added: 0002290 | |
| 2019-04-29 20:15 | (SW) Kerwin Chen | Assigned To | (SW) Kerwin Chen => (ALTech) Eric Kim |
| 2019-04-29 20:16 | (SW) Kerwin Chen | Status | assigned => resolved |
| 2019-04-29 20:16 | (SW) Kerwin Chen | Resolution | open => fixed |
| 2019-04-29 20:16 | (SW) Kerwin Chen | Note Added: 0002297 | |
| 2019-08-30 16:43 |
|
Status | resolved => closed |
| 2019-08-30 16:43 |
|
Note Added: 0002939 |
